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vices to telecommunication network customers from unau- 
thorized third parlies. A first router directs all connection 
requests to one or more secure web servers, which may 
utilize a load balancer to efiBciently distribute the session 
connection load among a high number of authorized client 
users. On the network side of the web servers, a second 
router directs all connection requests to a dispatcher server, 
which routes application server calls to a proxy server for the 
application requested. A plurality of data security protocols 
are also employed. The protocols provide for an identifica- 
tion of the user, and an authentication of the user to ensure 
the user is who he/she claims to be and a determination of 
entitlements that the user may avail themselves of within the 
enterprise system. Session security is described, particularly 
as lo the differences between a remote user's copper wire 
connection to a legacy system and a user's remote connec- 
tion lo the enterprise system over a "stateless"public 
Internet, where each session is a single transmission, rather 
than an interval of time between logon and logoff, as is 
customary in legacy systems. 
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SECURE SERVER ARCHITECTURE FOR 
WEB BASED DATA MANAGEMENT 

CROSS-RBFERENCE TO RELATED 

APPLICAnONS 5 

The following patent application claims the benefit of 
U.S. Provisional Patent Application U.S. Ser. No. 60/060, 
655, filed Sep. 26, 1997, entitled INTEGRATED CUS- 
TOMER INTERl^ACE SYSTEM FOR COMMUNICA- 
TIONS MANAGEMENT. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates in general to securing access is 
to a computer and computer data, and more particularly to 
a security methodology for securing access to an enterprise 
network or extranet having access from the public Internet. 

2. Background Art 

20 

In conventional remote connect computer systems, a 
connection is made with a large legacy system via a dial-up 
connection from a customer owned terminal, personal com- 
puter or workstation. This connection frequently, although 
not always, is a fixed copper connection through one or more 
telco central ofiSces and emulates a terminal addressable by 
the legacy systems and employs a security methodology 
dictated by the legacy system. The dial-up access requires 
custom hardware for a terminal or custom software for a 
workstation to provide a remote connection, lliis includes 
dial-up services, communication services, emulation and/or 
translation services and generally some resident custom 
form of the legacy application to interface with the midrange 
or mainframe computer running the legacy system. 

There are several problems associated with this approach. 35 
First, the aforementioned software is very hardware 
dependent, requiring multiple versions of software compat- 
ible with each of a wide range of workstations customers 
generally have. In addition, an extensive inventory of both 
software and user manuals for distribution to the outside 
customers is required if an enterprise desires to make its 
resources available to its customers. Moreover, installing the 
software generally requires an intensive effort on the cus- 
tomer and the software support team before any reliable and 
secure sessions are possible. ^5 

Secondly, dial-up, modem, and communications software 
interact with each other in many ways which are not always 
predictable to a custom application, requiring extensive 
trouble shooting and problem solving for an enterprise 
desiring to make the legacy system available to the 50 
customer, particularly where various telephone exchanges, 
dialing standards or signal standards are involved. 

Thirdly, although businesses are beginning to turn to the 
Internet to improve customer service and lower costs by 
providing Web-based support systems, when an enterprise 55 
desires to make more than one system available to the 
customer, the custom application for one legacy system is 
not able to connect to a different legacy system, and the 
customer must generally logoff, logon and re-authenticate to 
switch from one to the other. The security and entitlement 60 
features of the various legacy systems may be completely 
different, and vary from system to system and platform to 
platform. The security methodology used by the two legacy 
systems may be different, requiring different logon 
interfaces, user or enterprise IDs and passwords. Different 65 
machine level languages may be used by the two systems as 
for example, operating systems utilizing the 256 (-28) 
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character combination EBCDIC used by IBM, and 128 
(-27) character combination ASCII used by contemporary 
personal computers. 

It is therefore desired to provide remote customers with 
secure connectivity to enterprise legacy systems over the 
public Internet. The public Internet provides access connec- 
tivity world wide via the TCP/IP protocol, without need to 
navigate various disparate security protocols, telephone 
exchanges, dialing standards or signal standards, thereby 
providing a measure of platform independence for the 
customer. 

As contemplated with the present invention the customer 
can run their own Internet Web browser and utilize their own 
platform connection to the Internet to enable services. This 
resolves many of the platform hardware and connectivity 
issues in the customers favor, and leaves the choice of 
platform and operating system to the customer. Web-based 
programs can minimize the need for training and support 
since they utilize existing client software which the user has 
already installed and already knows how to use. Further, if 
the customer later changes that platform, then, as soon as the 
new platform is Internet enabled, service is restored to the 
customer. The connectivity and communications software 
burden is thus resolved in favor of standard and readily 
available hardware and the browser and software used by the 
public Internet connection. 

Secure World Wide Web (Web)-based online systems are 
now starting to emerge, generally using security protocols 
supplied by the browser or database vendors. These Web- 
based online systems usually employ HTTPS and a Web 
browser having Secure Sockets Layer (SSL) encryption, and 
they display Hypertext Markup Language (HTML) pages as 
a graphical user interface (GUI), and often include Java 
applets and Common Gateway Interface (CGI) programs for 
customer interaction. 

For the enterprise, the use of off-the-shelf Web browsers 
by the customer significantly simplifies the enterprise bur- 
den. Software development and support resources are avail- 
able for the delivery of the enterprise legacy services and are 
not consumed by a need for customer support at the work- 
station level. 

However, the use of the public Internet also introduces 
new security considerations not present in existing copper 
wire connections, as an open system increases the exposure 
to IP hijackers, sniffers and various types of spoofers that 
attempt to collect user IDs and passwords, and exposes the 
availability of the service to the users when the system is 
assaulted by syn-flooding, war dialers or ping attacks. These 
measures also need to be combined with traditional security 
measures used to prevent traditional hacker attacks, whether 
by copper wire or the Internet, that might compromise the 
enterprise system and its data. 

SUMMARY OF THE INVENTION 

The present invention is directed to a series of security 
protocols and an integrated system for the same that enables 
a remote user to interact with one or more application 
services provided by servers over the public Internet, or an 
enterprise Extranet. The present invention utilizes the Web 
paradigm and an integrated graphical user interface to allow 
easy and convenient access from the user's perspective, 
wherein the security provisions are transparent to the user, 
other than the entry of a customary user id and a strong 
password. 

In order to provide cross-platform software operability 
that is not dependent on a specific operating system or 
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hardware, the present invention is implemented using pro- 
gramming languages, such as Java"^" which only requires a 
Java^"** enabled Web browser. The system of the present 
invention includes an application backplane unit for con- 
trolling and managing the overall user interface system to a 
number of Web enabled application services, and a common 
security object for managing security and Java™ applets for 
a number of disparate services available from the servers. 

Each service includes its own user interface unit, referred 
heretofore as a client application, independently imple- 
mented of one another and the backplane. Although the 
client apphcations are independently developed as separate 
modules, the system of the present invention provides a 
capability of integrating the client applications and secured 
access thereto into one unified system, allowing users to 
access the individual client applications via the backplane 
unit and the security object. 

The present invention includes centralized user authenti- 
cation to insure that the remote user has valid access to the 
system. The authentication procedure generally includes a 
logon object which prompts for and accepts the user's name 
and password. The logon object then communicates the 
logon transaction to a server responsible for screening those 
remote users attempting to access services. Once a remote 
user has been authenticated by the system of the present 
invention, the user need not re-enter their name and pass- 
word each time the user accesses another server via the 
respective server's user interface program. In addition, each 
application may supplement the provided authentication 
procedure, with its own method of authentication by com- 
municating with its respective servers independently. 

Once a validated remote user is logged onto the system, 
the user is presented with a set of services which the remote 
user may obtain. The set of services available for each 
remote user is unique and depends on each user's subscrip- 
tions to the services. The set of service subscription, then 
forms the user's entitlements for the services. Thus, for 
example, if a user subscribes to a toll free network manage- 
ment service, the user is entitled to access information 
regarding the service. On the other hand, if the user does not 
subscribe to the toll free network manager service, that 
option is not available for the user to select. 

The present invention includes a user object to represent 
a current user logged onto the system. This user object, inter 
alia, is responsible for obtaining from a server the current 
user's information including the user's entitlements to vari- 
ous services. Tlie backplane uses the entitlement informa- 
tion to provide only those services available to the user. As 
explained previously, the backplane will not enable the 
services to which the user does not have the entitlements, 
effectually blocking the user from accessing those services. 

In addition, the user information is maintained for the 
duration of a logon session, allowing both the backplane and 
the client applications to access the information as needed 
throughout the duration of the session. The backplane and 
the client applications use the information to selectively 
provide services to users. Accordingly, it is yet another 
object of the present invention to provide a mechanism for 
retrieving and maintaining user information and entitle- 
ments such that they are available to processes and threads 
running on the remote client platform without having to 
communicate with a server every time the information is 
needed. 

ITie system of the present invention implements a "keep 
alive message" passed between a client and a server, also 
called a "heartbeat." For example, a keep alive message is 
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sent every predefined period, e.g., 1 minute from a client 
application to the server. When the client application fails to 
heartbeat consecutively for a predetermined period of time, 
for example, one hour, the server treats this client applica- 

5 tion as having exited by closing the application and per- 
forming cleanup routines associated with the application. 
This mechanism effectively prevents unauthorized access 
unwanted sessions from remaining open in the event of 
client application failures or user neglect. Accordingly, it is 

10 a further object of the present invention to provide a mecha- 
nism for detecting communication failures among the "state- 
less" processes running the present invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the present invention will now 
be described, by way of example only, with reference to the 
accompanying drawings in which: 

FIG. 1 is a diagrammatic overview of the architectural 
2Q framework of an enterprise Internet network system; 

FIG. 2 is an illustrative example of a backplane architec- 
ture schematic as invoked from a home page of the present 
system; 

FIG. 3 illustrates an example client GUI presented to the 
25 client/customer as a browser Web page; 

FIG. 4 is a diagrammatic overview of the software archi- 
tecture of the enterprise Internet network system. 

FIG. 5 is a diagram depicting the physical network 
architecture in the system of the present invention; 

FIG. 6 is an example illustrating a logon Web page of the 
present invention; 

FIG. 7 is a diagram illustrating a security module design 
having clean separation from the browser specific imple- 
35 mentations; 

FIG. 8 is a schematic illustration of the message format 
passed from the user workstation 10 to the secure web server 
24 over the pubhc Internet; 

FIG. 9 is a high head functional overview of the commu- 
nications and encryption protocols between the web server 
and the Dispatcher server; 

FIG. 10 is a flow diagram illustrating a logon process to 
the system of the present invention; 
^5 FIG. 11 is a data flow diagram illustrating the present 
invention's process flow during logon, entitlement request/ 
response, heartbeat transmissions and logoff procedures; 

FIG. 12 is a data flow diagram for various transactions 
communicated in the system of the present invention; 
50 FIG. 13(a) is a schematic illustration showing the mes- 
sage format passed between the Dispatcher server and the 
application specific proxy; 

FIG. 13(6) is a schematic illustration of the message 
format passed between the application specific proxy back to 
55 the Dispatcher server; 

FIG. 14 is a diagram illustrating a hierarchical architec- 
ture of DMZ web servers utilizing a file server; 

FIG. 15 is a diagram illustrating a hierarchical architec- 
ture of DMZ web servers, each having a local disk; and 

FIG. 16 is a diagram illustrating Application Security 
process flow. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

The present invention is directed to a series of security 
protocols and procedures used to protect an integrated 
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system that enables a remote user to interact with one or 11, one or more backplane service objects 12 for managing 

more enterprise applications provided by servers over the sessions, one or more presentation services objects 13 for the 

public Internet, or an enterprise Extranet. The present inven- presentation of customer options and customer requested 

tion utilizes the Web paradigm and an integrated graphical ^^^^a in a browser recognizable format and a customer 

user interface to allow easy and convenient access from the 5 supplied browser 14 and operating system environment for 

user's perspective, wherein the security provisions are trans- presentation of customer options and data to the customer 

parent to the user, other than the entry of a customary user Internet communications over the public Internet, 

id and a strong password. ^ second or middle tier 16 is provided, having secure web 

. - ^ . .,t • t J servers 24 and back end services to provide applications that 

-nie discussion of the present mvention wiU include an ^3j^blish user sessions, govern user authentication and their 

overview of the system in which the various security pro- lO entitlements, and communicate with adaptor programs to 

tocols function and detailed discussions of Communications simplify the interchange of data across the network. 

Security, User Identification and Authentication, Session Aback end or third tier 18 having applications directed to 

Security, Enterprise Security and Application security. legacy back end services includes database storage and 

Communications security relates to the authenticity of the retrieval systems and one or more database servers for 

enterprise web server and th'e security of the transmitted data accessing system resources from one or more legacy sys- 

through an implementation of the Secure Sockets Layer 20. 

fSSL) version of HTTPS Generally, as explained in co-pending U.S. Pat. applica- 

,/ . ,\ . . . . , tion No. 09/159,515, filed Sep. 24, 1998, now U.S. Pat. No. 

User Identification and Authentication relates to an iden- ^^^Sm. entitled GRAPHICAL USER INTERFACE FOR 

tification of the user an authentication of the user to ensure web ENABLED APPLICAOONS, the disclosure of which 

the user is who he/she claims to be and a determination of ^ incorporated herein by reference thereto, the customer 

entitlements that the user may avail themselves of within the workstation 10 includes client software capable of providing 

enterprise system. ^ platform-independent, browser-based, consistent user 

Session Security is directed to the differences between a interface implementing objects programmed to provide a 

remote user's copper wire connection to a legacy system and 25 reusable and common GUI and problem-domain abstrac- 

a user's remote connection to the enterprise system over a tjons. More specifically, the client-tier software is created 

"stateless" public Internet, where each session is a single and distributed as a set of Java classes including the applet 

transmission, rather than an interval of time between logon classes to provide an industrial strength, object-oriented 

and logoff, as is customary in legacy systems. environment over the Internet. Application-specific classes 

Enterprise Security is directed to the security of the 30 are designed to support the functionality and server inter- 

enterprisc network and the data maintained by the various faces for each application with the functionafity delivered 

enterprise applications with respect to attacks on the system through the system being of two-types: 1) cross-product, for 

or data. example, inbox and reporting functions, and 2) product 

specific, for example. Toll Free Network Manager or Broad- 

ARCHITECTURAL OVERVIEW OF THE WEB- 35 band Manager functions. The system is capable of delivering 

ENABLED SYSTEM to customers the functionality appropriate to their product 

The web-enabled system in which the present security .... ^ . , . 

protocols are found is basically organized as a set of ™- ^ ^ a diagrammatic illustration of the network and 

common components which together are known as network- V^^^^ovm components of the networkMCI Interact system, 

MCI Interact, which includes the following major compo- ^« !?'^'^^i"iv^wS^^''"'f' workstation 10; the Demilitarized 

jjgj^jj, B J I' 2x)ne 17 (DMZ); a cluster of Web Servers 24; the MCI 

* , . J ^ ^. , L Dispatcher Server 26; the MCI application servers 40, and 

1) an object oriented software architecture detailing the the legacy systems 20 
clientandserverbasedaspecLsofnetworkMCIInteract; ^^^^^^^ workstation 10 is browser enabled and 

2) a network architecture defimng the physical network 45 includes client applications responsible for presentation and 
needed to satisfy the security and data volume require- front-end services. Its functions include providing a user 
ments of networkMCI Interact; interface to various MCI services and supporting commu- 

3) a data architecture detailing the application, back-end nications with MCFs Intranet web server cluster 24. As 
or legacy data sources available for networkMCI Inter- illustrated in FIG. 2, and more specifically described in the 
act; and, 50 above -referenced co-pending U.S. Patent Application 

4) an infrastructure covering security, order entry, GRAPHICAL USER INTERFACE FOR WEB ENABLED 
fulfillment, billing, self -monitoring, metrics and sup- APPLICATIONS, the client tier software is responsible for 
port. presentation services to the customer and generally includes 

Each of these common component area will be generally a web browser 14 and additional object-oriented programs 

discussed herein below. A detailed description of each of 55 residing in the client workstation platform 10. The client 

these components can be found in a related, co-pending U.S. software is generally organized into a component architec- 

patent application No. 09/159,695, filed Sep. 24, 1998, ture with each component generally comprising a specific 

entitled INTEGRATED CUSTOMER INTERFACE SYS- application, providing an area of functionality. The applica- 

TEM FOR COMMUNICATIONS NETWORK tions generaUy are integrated using a "backplane" services 

MANAGEMENT, the disclosure of which is incorporated 60 layer 12 which provides a set of services to the application 

herein by reference thereto. objects which provide the front end business logic 11 and 

FIG. 1 is a diagrammatic illustration of the software manages their launch. The networkMCI Interact common 

architecture in which the present invention functions. A first set of objects provide a set of services to each of the 

tier of software services are resident on a customer work applications such as: 1) session management; 2) application 

station 10 and provides customer access to the enterprise 65 launch; 3) inter-applicalion communications; 4) window 

system, having one or more downloadable application navigation among applications; 5) log management; and 6) 

objects directed to front end business logic as indicated at version management. 
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The primary common object services include: graphical 
user interface (GUI); communications; printing; user 
identity, authentication, and entitlements; data import and 
export; logging and statistics; error handling; and messaging 
services. 

FIG. 2 is an diagrammatic example of a backplane archi- 
tecture scheme illustrating the relationship among the com- 
mon objects. In this example, the backplane services layer 
12 is programmed as a Java applet which can be loaded and 
launched by the web browser 14. With reference to FIG. 2, 
a typical user session starts with a web browser 14 creating 
a backplane 12, after a successful logon. The backplane 12, 
inter alia, presents a user with an interface for networkMCI 
Interact application management. A typical user display 
provided by the backplane 12 may show a number of 
applications the user is entitled to run, each application 
represented by buttons depicted in FIG, 2 as buttons 58 a, b, 
c selectable by the user. As illustrated in FIG. 2, upon 
selection of an application, the backplane 12 launches that 
specific application, for example, Service Inquiry 54a or 
Alarm Monitor 54i, by creating the application object. In 
processing its functions, each application in turn, may utilize 
common object services provided by the backplane 12. FIG. 
2 shows graphical user interface objects 56a, b created and 
used by a respective application 54a, b for its own presen- 
tation purposes. 

FIG. 3 illustrates an example client GUI presented to the 
client/customer as a browser web page 60 providing, for 
example, a suite 70 of network management reporting 
applications, which may include: TraflBc Monitor 72; a 
Monitor 73; a Network Manager 74 and Intelligent Routing 
75. Access to network functionality is also provided through 
Report Requester 76, which provides the ability to define 
and request a variety of reports for the client/customer and 
a Message Center 77 for providing enhancements and func- 
tionahty to traditional e-mail communications by providing 
access to user requested reports and bulk data. Additional 
network MCI Internet applications not illustrated in FIG. 3 
include Online Invoice, relating to electronic invoicing and 
Service Inquiry related to Trouble Ticket Management. 

As shown in FIGS. 2 and 3, the browser resident GUI of 
the present invention implements a single object, COBack- 
Plane which keeps track of all the client applications, and 
which has capabilities to start, stop, and provide references 
to any one of the cUent applications. 

The backplane 12 and the client applications use a 
browser 14 such as the Microsoft Internet Explorer versions 
4.0.1 or higher for an access and distribution mechanism. 
Although the backplane is initiated with a browser 14, the 
cUenl applications are generally isolated from the browser in 
that they typically present their user interfaces in a separate 
frame, rather than sitting inside a Web page. 

The backplane architecture is implemented with several 
primary classes. These classes include COBack Plane, 
COApp, COAppImpl, COParm. and COAppFrame classes. 
COBackPlane 12 is an application backplane which 
launches the applications 54«, S4b, typically implemented as 
COApp. COBackPlane 12 is generally implemented as a 
Java applet and is launched by the Web browser 14. This 
backplane applet is responsible for launching and closing the 
COApps. 

When the backplane is implemented as an applet, it 
overrides standard Applet methods initQ, startQ, stopQ and 
runQ. In the initQ method, the backplane applet obtains a 
CO User user context object. The COUser object holds 
information such as user profile, applications and their 
entitlements. The user's configuration and application 
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entitlements provided in the COUser context are used to 
construct the application toolbar and Inbox applications. 
When an application toolbar icon is clicked, a particular 
CO>^p is launched by launchAppQ method. The launched 

5 application then may use the backplane for inter-application 
communications, including retrieving Inbox data. 

The COBackPlane 12 includes methods for providing a 
reference to a particular COApp, for interoperatioo. For 
example, the COBackPlane class provides a getAppQ 
method which returns references to application objects by 
name. Once retrieved in this manner, the application object's 
public interface may be used directly. 

The use of a set of common objects for implementing the 
various functions provided by the system of the present 
invention, and particularly the use of browser based objects 

^5 to launch applications and pass data therebetween is more 
fully described in the above referenced copending applica- 
tion GRAPHICAL USER INTERFACE FOR WEB 
ENABLED APPLICATIONS, and Appendix A, attached to 
that application, provides descriptions for the common 

20 objects which includes various classes and interfaces with 
their properties and methods. 

As shown in FIG. 4, the aforesaid objects will commu- 
nicate the data by establishing a secure TCP messaging 
session with one of the DMZ networkMCI Interact Web 

25 servers 24 via an Internet secure communications path 22 
estabhshed, preferably, with a secure sockets SSL version of 
HTTPS. The DMZ networkMCI Interact Web servers 24 
function to decrypt the client message, preferably via the 
SSL implementation, and unwrap the session key and verify 

30 the users session. After establishing that the request has 
come from a valid user and mapping the request to its 
associated session, the DMZ Web servers 24 will re-encrypt 
the request using symmetric encryption and forward it over 
a second secure socket connection 23 to the dispatcher 

35 server 26 inside the enterprise Intranet. 

As will be hereinafter described in greater detail, a 
networkMCI Interact session is designated by a logon, 
successful authentication, followed by use of server 
resources, and logoff. However, the world-wide web com- 

40 munications protocol uses HTTP, a stateless protocol, each 
HTTP request and reply is a separate TCP/IP connection, 
completely independent of all previous or future connections 
between the same server and client. The present invention is 
implemented with a secure version of HTTP such as 

45 S-HTTP or HTTPS, and presently utilizes the SSL imple- 
mentation of HTTPS. The preferred embodiment uses SSL 
which provides a cipher spec message which provides server 
authentication during a session. The preferred embodiment 
further associates a given HTTPS request with a logical 

50 session which is initiated and tracked by a "cookie jar 
server" 32 to generate a "cookie" or session identifier which 
is a unique server-generated key that is sent to the client 
along with each reply to a Hl'l PS request. The client holds 
the cookie or session identifier and returns it to the server as 

55 part of each subsequent HTTPS request. As desired, either 
the Web servers 24, the cookie jar server 32 or the Dis- 
patcher Server 26, may maintain the "cookie jar" to map the 
session identifier to the associated session. A separate cookie 
jar server 32, as illustrated in FIG. 4 has been found 

60 desirable to minimize the load on the dispatcher server 26. 
A new cookie will be generated when the response to the 
HTTPS request is sent to the client. This form of session 
management also functions as an authentication of each 
HTTPS request, adding an additional level of security to the 

65 overall process. 

As illustrated in FIG. 4, after one of the DMZ Web servers 
24 decrypts and verifies the user session, it forwards the 
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message through a firewall 296 over a TCP/IP connection 23 MCI management personnel. As shown in FIG. 4, other 

to the dispatcher server 26 on a new TCP socket while the legacy or host platforms 20(6), 20(c) and 20(^0 may also 

original socket 22 from the browser is blocking, waiting for communicate individually with the Intranet servers for ser- 

a response. The dispatcher server 26 will unwrap an outer vicing specific transactions initiated at the client browser, 

protocol layer of the message from the DMZ server cluster 5 The illustrated host platforms 20(a)-(d) are illustrative only 

24, and will reencrypt the message with a different encryp- and it is understood other host platforms may be interpreted 

tion key and forward the message to an appropriate appli- into the network architecture illustrated in FIG. 4 through an 

cation proxy via a third TCP/IP socket 27. While waiting for intermediate midrange server 40. 

the proxy response all three of the sockets 22, 23, 27 will be Each of the individual proxies may be maintained on the 
blocking on a receive. While either symmetric or public key lO dispatcher server 26, the related application server, or a 
encryption can be used, in the preferred embodiment, public separate proxy server situated between the dispatcher server 
key encryption is utilized, with the "public" keys used 26 and the midrange server 40. The relevant proxy waits for 
between components of the network, kept secret. A different requests from an application client running on the custom- 
public key may be employed for communicating between er's workstation 10 and then services the request, either by 
the dispatcher 26 to the webservers 24 than is used from the 15 handling them internally or forwarding them to its associ- 
webserver 24 to the dispatcher 26. Specifically, once the a ted Intranet application server 40. The proxies additionally 
message is decrypted, the wrappers are examined to reveal receive appropriate responses back from an Intranet appli- 
the user and the target middle -tier (Intranet application) cation server 40. Any data returned from the Intranet appli- 
scrvice for the request. A first-level validation is performed, cation server 40 is translated back to client format, and 
making sure that the user is entitled to communicate with the 20 returned over the Internet to the client workstation 10 via the 
desired service. The user's entitlements in this regard are Dispatcher Server 26 and at one of the web servers in the 
fetched by the dispatcher server 26 from StarOE server 49 DMZ Services cluster 24 and a secure sockets connection, 
at logon time and cached. When the resultant response header and trailing apphcation 
If the requestor is authorized to communicate with the specific data are sent back to the client browser from the 
target service, the message is forwarded to the desired 25 proxy, the messages will cascade all the way back to the 
service's proxy. Each application proxy is an application browser 14 in real time, limited only by the transmission 
specific daemon which resides on a specific Intranet server, latency speed of the network. 

shown in FIG. 4 as a suite of mid -range servers 40. Each The networkMCI Interact middle tier software includes a 

Intranet application server of suite 40(fl) is generally respon- communications component offering three (3) types of data 

sible for providing a specific back-end service requested by 30 transport mechanisms: 1) Synchronous; 2) Asynchronous; 

the client, and, is additionally capable of requesting services and 3) Bulk transfer. Synchronous transaction is used for 

from other Intranet application servers by communicating to situations in which data will be returned by the application 

the specific proxy associated with that other application server 40 quickly. Thus, a single TCP connection will be 

server. Thus, an application server not only can offer its made and kept open until the full response has been 

browser a client to server interface through the proxy, but 35 retrieved. 

also may offer all its services from its proxy to other Asynchronous transaction is supported generally for situ- 

application servers. In effect, the application servers request- ations in which there may be a long delay in application 

ing service are acting as clients to the application servers server 40 response. Specifically, a proxy will accept a 

providing the service. Such mechanism increases the secu- request from a customer or client 10 via an SSL connection 

rity of the overall system as well as reducing the number of 40 and then respond to the client 10 with a unique identifier and 

interfaces. close the socket connection. The client 10 may then poll 

The network architecture of FIG. 4 may also include a repeatedly on a periodic basis until the response is ready, 

variety of application specific proxies having associated Each poll will occur on a new socket connection to the 

Intranet application servers including: a StarOE proxy for proxy, and the proxy will either respond with the resultant 

the StarOE application server 49 for handling authentication 45 data or, respond that the request is still in progress. This will 

order entry/billing; an Inbox proxy for the Inbox application reduce the number of resource consuming TCP connections 

server 41, which functions as a container for completed open at any time and permit a user to close their browser or 

reports, call detail data and marketing news messages, a disconnect a modem and return later to check for results. 

Report Manager Proxy capable of communicating with a Bulk transfer is generally intended for large data transfers 

system-specific Report Manager server 42 for generating, 50 and are unlimited in size. Bulk transfer permits cancellation 

managing and scheduling the transmission of customized during a transfer and allows the user to resume a transfer at 

reports including, for example: call usage analysis inform a- a later point in time. 

tion provided from the StarODS server 43; network trafiic The DMZ Web servers 24 are found in a special secure 

analysis/monitor information provided from the Traffic view network area set aside from the Intranet to prevent poten- 

server 44; virtual data network alarms and performance 55 tially hostile customer access. AH DMZ equipment is physi- 

reports provided by Broadband server 45; trouble tickets for cally isolated and firewalled as illustrated at 29(fl), 29(b) 

switching, transmission and traffic faults provided by Ser- from the company Intranet. Similarly, the DMZ equipment 

vice Inquiry server 46; and toll free routing information is firewalled and obscured from hostile attacks from the 

provided by Toll Free Network Manager server 47. public Internet, except for limited web browser access to the 

As partially shown in FIG. 4, it is understood that each 60 web servers which are located in the DMZ. The customer's 

midrange server of suite 40 communicates with one or web browser connects to a web server in the DMZ which in 

several consolidated network databases which include each turn connects to the Dispatcher server 26 which acts as a 

customer's network management information and data. In proxy to extract select information from midrange servers 40 

the present invention the Services Inquiry server 46 includes located in the company Intranet. A user may not directly 

communication with MCFs Customer Service Management 65 connect to any enterprise server in the enterprise Intranet, 

legacy platform 20(fl). Such network management and cus- thus ensuring internal company system security and integ- 

tomer network data is additionally accessible by authorized rity. 
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The DMZ also isolates the company Intranet from the but in the preferred embodiment utilizes the Secure Sockets 
public Internet because the web servers 24 located in the Layer (SSL) protocol developed by Netscape Communica- 
DMZ never store or compute actual customer sensitive data. tions. It is noted that these solutions are intended for use with 
The web servers only put the data into a form suitable for IPv4, and that IPv6, presently under comment by the Inter- 
display by the customer's web browser. Since the DMZ web 5 net Engineering Steering Group, may enable secure trans- 
servers 24 do not store customer data, there is a much missions between client and server without resort to propri- 
smaller chance of any customer information being jeopar- etary protocols. The remaining security protocols of the 
dized in case of a security breach. present invention may be used with IPv6 when it becomes 

All reporting is provided through the Message Center an available standard for secure IP communications. 
(Inbox) and a Report Requestor application interface which lO The SSL component of the HTTPS also includes non- 
supports spreadsheets, a variety of graph and chart types, or repudiation techniques to guarantee that a message originat- 
both simultaneously. For example, the spreadsheet presen- ing from a source is the actual identified sender. One 
tation allows for sorting by any arbitrary set of columns. The technique employed to combat repudiation includes use of 
report viewer may also be launched from the Message an audit trail with electronically signed one-way message 
Center (Inbox) when a report is selected. 15 digests included with each transaction. This technique 

By associating each set of report data which is down- employs SSL pubhc-key cryptography with one-way hash- 
loaded via the inbox with a small report description object, ing functions. 

it is possible to present most reports without report -specific Another communications issue involving the secure corn- 
presentation code (the report-specific code is in the con- munications link, is the trust associated with allowing the 
struction of the description object). These description 20 download of the Java common objects used by the present 
objects are referred to as "metadata/' or "data about data." invention, as discussed earlier with respect to the browser, 
At one level, they function like the catalog in a relational since the Java objects used in the present invention require 
database, describing each row of a result set returned from that the user authorize disk and I/O access by the Java object, 
the middle tier as an ordered collection of columns. Each Digital Certificates, such as those developed by VeriSign, 
column has a data type, a name, and a desired display 25 Inc. entitled VeriSign Digital ID™ provide a means to 
format, etc. Column descriptive information will be stored in simultaneously verify the server to the user, and to verify the 
an object, and the entire result set will be described by a list source of the Java object to be downloaded as a trusted 
of these objects, one for each column, to allow for a standard source as will hereinafter be described in greater detail, 
viewer to present the result set, with labeled columns. As illustrated in FIG. 10, the process starts with the 
Nesting these descriptions within one another allows for 30 remote customer browser 10 (FIG. 4) launch as indicated at 
breaks and subtotaling at an arbitrary number of levels. This step 280, and the entry of the enterprise URL, such as 
further enhances the security for the customer data, for HTTPS ://www.ente rprise.com as indicated at step 282. Fol- 
without the meta-data associated with the report, the report lowing a successfiil connection, the SSL handshake protocol 
data is essentially a meaningless block of data. is initiated as indicated at step 283. When a SSL client and 
Communications Security 35 server first start communicating, they agree on a protocol 

Communications security, which relates to the authentic- version, select cryptographic algorithms, authenticate the 
ity of the enterprise web server and the security of the server (or optionally authenticate each other) and use public- 
transmitted data will be described with respect to an imple- key encryption techniques to generate shared secrets. These 
mentation in the preferred embodiment of the invention of processes are performed in the handshake protocol, which 
the Secure Sockets Layer (SSL) version of HITPS. 40 can be summarized as follows: The client sends a client hello 

In order for a communication to be secure, it must be message to which the server must respond with a server 

known that the message comes from the correct source, that hello message, or else a fatal error will occur and the 

it arrives at the correct destination, that it has not been connection will fail. The client hello and server hello are 

modified, and has not been intercepted and understood by a used to estabhsh security enhancement capabilities between 

third party. Normal encryption protects against understand- 45 client and server. The client hello and server hello establish 

ing the message, even if intercepted, and certain types of the following attributes: Protocol Version, Session ID, 

cipher encryption provide the ability to determine that the Cipher Suite, and Compression Method. Additionally, two 

message has been tampered with and in some cases recon- random values are generated and exchanged: ClientHello.r- 

struct the message even if intercepted and intentionally andom and Serve rHello .random. 

garbled. The disadvantage of normal encryption is the 50 Following the hello messages, the server will send its 

difiBculty associated with the secure distribution and updates digital certificate. Alternately, a server key exchange mes- 

of the keys used for encryption and decryption. sage may be sent, if it is required (e.g. if their server has no 

Public key encryption solves the distribution and update certificate, or if its certificate is for signing only). Once the 

problem, but does not, for the public Internet, ensure the server is authenticated, it may optionally request a certificate 

identity of the party with whom one is communicating. A 55 from the client, if that is appropriate to the cipher suite 

spoofer who appropriates the DNS address of an enterprise selected. 

for a leg of the Internet can substitute the spoofers public key The server will then send the server hello done message, 

for the public key of the enterprise with whom the user is indicating that the hello-message phase of the handshake is 

attempting to communicate, thereby fooling the user into complete. The server will then wail for a client response. If 

revealing the user name and password used on the enterprise 60 the server has sent a certificate request Message, the client 

system. To avoid this problem, digital signatures have been must send either the certificate message or a no_certificate 

developed to ensure the identity of the sender. They also, alert. The client key exchange message is now sent, and the 

simultaneously, commit the sender to the message, avoiding content of that message will depend on the public key 

subsequent repudiation. algorithm selected between the client hello and the server 

TtiG communications link between the enterprise and the 65 hello. If the client has sent a certificate with signing ability, 

user may be secured with S-HTFP, HTITS, or proprietary a digitally-signed certificate verify message is sent to explic- 

encryption methodologies, such as VNP or PPTP tunneling, itly verify the certificate. 
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At this point, a change cipher spec message is sent by the decode/dispatcher server 26 then authenticates the user's 

client, and the client copies the pending Cipher Spec into the access to tJie desired middle-tier service from cached data 

current Cipher Spec. The client then immediately sends the previously received from the StarOE server as will be 

finished message under the new algorithms, keys, and hereinafter described in greater detail in connection with 

secrets. In response, the server will send its own change 5 User Identification and Authentication, 

cipher spec message, transfer the pending to the current shown in FIG. 4, the Secure Web server 24 forwards 

Cipher Spec, and send its finished message under the new Dispatcher header and proxy-specific data to the Dis- 

Cipher Spec At this pomi, the handshake is complete and ^^^^^^ 5^^^^ 26 "enriched" with the identity of the user 

the client and server may begin to exchange user layer data. ^^^^^ session-related information) as provided by 

10 the session data/cookie mapping, the target proxy identifier 

and the proxy-specific data. Tlie dispatcher server 26 

Client Server receives the requests forwarded by the Secure Web server(s) 

CUentHello > 24 and dispatches them to the appropriate application server 

ServerHello qj- proxy. The message wrappers are examined, revealing 

„ „ Certificate* ^ j target middle-tier service for the request. A 

Ser\'crKcyExchange* _ , , , - , , 

CcrtificatcRequcsf first-level validation is performed, making sure that the user 

< ScrvcriieiioDonc is entitled to communicate with the desired service. The 

Certificate* user's entitlements in this regard are fetched by the dis- 

ciicntKeyExchange ^^j^^^. ^^^^ ^^^^ Si^TO£ server 217 at logon time and 

Certificate Verify* . . * - . , • x • t 

[CbangcCipherSpec] 20 Cached. Assuming that the Requestor is authorized to corn- 
Finished > municate with the target service, the message is then for- 

[ChangeCipherSpec] warded to the desired servicers proxy. Each of these proxy 
Finished ^ processes may performs: a validation process for examining 

Login Data < > Login HTML incoming requests and confirming that they include validly 

25 formatted messages for the service with acceptable param- 

*indicatcs optional or situation-dependent messages that are not always eters; a translation process for translating a message into an 

underlying message or networking protocol; and, a manage- 

FIG. 8 is a schematic illustration of a logical message ment process for managing the communication of the spe- 

format sent firom the client browser to the desired middle tier cific customer request with the middle-tier server to actually 

server for a particular application. 30 get the request serviced. Data returned from the middle-tier 

As mentioned herein with respect to FIG. 4, the messages server is translated back to client format, if necessary, and 

created by the client Java software are transmitted to the returned to the dispatcher server as a response to the request, 

secure Web Servers 24 over HTTPS. For incoming (client- It should be understood that the application server proxies 

to-server) communications, the Secure Web servers 24 can either reside on the dispatcher server 26 itself, or, 

decrypt a request, authenticate and verify the session infor- 35 preferably, can be resident on the middle-tier appHcation 

raation. The logical message format from the client to the server, i.e., the dispatcher front end code can locate proxies 

Web server is shown as follows: ||TCP/1P | [encryption ||http resident on other servers. 

||web header dispatcher header | [proxy-specific data || User Identification and Authentication 

FIG. 6 is an illustrative example of a logon Web page of 

where "||" separates a logical protocol level, and protocols 40 the present invention. At the time of logon, the SSL protocol 

nested from left to right. FIG. 8 illustrates a specific message handshake has been completed, and the logon object and the 

sent from the client browser to the desired middle tier server HTML logon page 230 are the first items to be downloaded, 

for the particular appHcation. As shown in FIG. 8, the chent Typically the logon page includes name 232 and password 

message 100 includes an SSL encryption header 110 and a 234 fields for user to enter. The logon page 230, in addition, 

network-level protocol HTTP/POST header 112 which are 45 may include hyper links 236 to other services such as 

decrypted by the Secure web Server(s) 24 to access the product and service center, programs and promotions, and 

underlying message; a DMZ Web header 114 which is used questions and answers concerning the system of the present 

to generate a cookie 111 and transaction type identifier 116 invention. 

for managing the client/server session; a dispatcher header In the preferred embodiment, the invention uses a browser 

115 which includes the target proxy identifier 120 associated 50 such as the Microsoft Internet Explorers versions 4.0.1 or 

with the particular type of transaction requested; proxy higher as the default browser for access and Java object 

specific data 125 including the application specific metadata distribution. Tlie present invention provides an additional 

utiUzed by the target proxy to form the particular messages COSecurity module which is downloaded with the logon 

for the particular middle tier server providing a service; and, page and wraps the security functionality of specific brows- 

the network-level HTTP/POST trailer 130 and encryption 5S ers available off-the-shelf. 

trailer 135 which are also decrypted by the secure DMZ Web Downloading the Java objects presents a problem for the 
server 24. Alternately, as illustrated in FIG. 5, an alternate enterprise, since Netscape Communicator™, Microsoft 
message format may be used, as for example between the Internet Explorer"^" and Sun's HotJava™ employ different 
client workstation 10 and the RTM web server 52. techniques for downloading Java applets and classes, and it 
Referring to FIG. 4, after establishing that the request has 60 must be determined which browser the user is using before 
come from a valid remote user and mapping the request to downloading the Java objects and classes, 
its associated session, the request is then forwarded through The browser type is also communicated to assist the 
the firewall 29b over a socket connection 23 to one or more enterprise in determining how the Java common objects 
decode/dispatcher servers 26 located within the corporate should be downloaded. Netscape Communicator™ and Hot- 
Intranet 30. The messaging sent to the Dispatcher Server 26 65 Java™ download Java objects in one or more JAR files, 
will include the user identifier and session information, the while Microsoft Internet Explorer presently uses CAB files 
target proxy identifier, and the proxy specific data. The for the same purpo.se. Microsoft CAB (cabinet) files are 
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equivalent to JAR files. The CAB files are used in the 
preferred embodiment of the invention for two reasons. 

First, for convenience in downloading class files so that they 7; ~ \ T ~~ \ 

, „ ,1 ♦ .u T-u if .1 // [nstanttating COSccunty objcctCOSccunty 

are locally resident on the PC. The browser tools, common security - new CoSecurityQ; 

objects and application class files are zipped up and down- ^ // Now access a privileged resource 

loaded to the Java trusted library directory. Only trusted, i.e. i 

signed, applets can make use of these class files. Secondly, ^curity.g'tSystemPropertyruser.home"); 

sigmng an applet, and obtaining permission from the user, Systein.oui.printin(s); 

enables the Java objects to break out of the "sandbox" and } 

get around Java security restrictions, and enable local disk 10 catch(COSccurityException cose) 

and file access and system I/O such as printing. Signed ^ ^ ^^^^p^^^ 

applets enable the user to verify the applets as bemg from a j 

trusted source and allow applets to write to the local disk, 

print, read local files, and connect to a server other than the „ . ... r-t^ .i_ l . 1. l 

th^t i„ f«r i^t u« 1S Referring back to FIG. 10, once the browser type has been 

one that launches the applet. In order for an applet to be , , 1 * u 1 ^ *u / j 
. • J- •* I ^ A * . u • J confirmed, the logon applet checks for the name/password 
signed the applet r^uires a digital certificate to be assigned instantiltes a^ssion object in step 292, commu- 
te, a JAR (Java ARchive) or equivalent archive file. As ^^^^ name/password pair to the enterprise system, 
discussed previously, this digital certificate may be a soft- -j^^ ^^^^ object sends a message containing the name/ 
ware publisher certificate or the certificate used to verify the password to the StarOE server 49 for user validation in step 
server as a trusted server during the SSL handshake process. 20 

FIG. 7 is a diagram which illustrates a security module When the user is properly authenticated by the server in 

design having clean separation from the browser specific step 296, another Web page which launches the backplane 

implementations. The security module includes the main object is downloaded in steps 298, 300, 304. This page is 

COSecurity class 402, and the interface COBrowserSecuri- referred to as a home page. At the same time, all the 

tylnterface 404. The COSecurity object checks browser type remaining application software objects are downloaded in 

upon instantiation. It does so by requesting the "java.ven- CAB or JAR files as indicated at step 302. If the system of 

dor" system properly. In the preferred embodiment of the '^e present invention determines that the backplane and 

invention, Microsoft Internet Explorer™ is the default ?PP''?'i°°J'*=' ""^^^ already downloaded, the steps 

browser, but if the browser is Netscape, for example, the ^OO. 302, 304 are not performed. Tlie backplane object is 

class then instantiates by name the concrete implementation 3° . , 

of the Netscape security interface, nmco.security.security- , *' ^ previously, shows an examp e of a 

impls. C0Netscape4 0 Securitylmpl 406. Otherwise, it home page, typically a new Web page having the backplane 

instantiates nmco.sec^rity.securityimpls. CODefaultSecuri- ho^f P»g« «» is downloaded after the authen- 

tvlmpl 408 tication via the logon page. The home page 60 comprises 

^ r, . , ^ . . .35 icons 70 for each of the application services as well as an 

TTie COBrowserSecuntylnterf^^^ 404 mirrors the meth- ligation tool bar 254 for invoking the services. The 

ods provided by COSecunty 402. Concrete implementations ^ ^^^^^^ t^ol bar 254 is different from the icons 70 in that 

such as C0Netscape4 OOSecuntylmpl 406 for Netscape application tool bar 254 remains on a screen, even when 

Commumcator and CODefaultSecuritylmpl 408 as a default ^ome page 60 is no longer displayed. The home page 

are also provided. Adding a new implementation 410 is as ^j^^ .^^jj ^ses HTML links to other services 256. 

easyas implementmgtheCOBrowserSecuntyInterface,and ^^^^^ information center, features 

adding in a new hook m COSecunty. htnt^ts, or a link 259 to the networkMQ Interact support 

After using "java.vendor*' to discover what browser is center for the system of the present invention, 

being used, COSecurity 402 instamiates by name the appro- Referring again to FIG. 10, the backplane communicates 

priate concrete implementation. This is done by class load- 45 with the StarOE server 49 to retrieve the user*s entitlements 

ing first, then using Class.newInslanceQ to create a new in step 308. The entitlements represent specific services the 

instance. The newinstanoeQ method returns a generic object; user has subscribed and has privilege to access. It also 

in order to use it, it must be cast to the appropriate class. describes what entitlements the user may have within any 

COSecurity 402 casts the instantiated object to COBrows- single service. For example, from the COUser context, the 

erSecuritylnterface 404, rather than to the concrete imple- 50 backplane can obtain the list of applications that the user is 

mentation. COSecurity 402 then makes calls to the entitled to access. In addition, each COApp holds set of 

COBrowserSecuritylnterface "object," which is actually a entitlements within that application in COAppEntitlements 

concrete implementation "in disguise." This is an example object. 

of the use of object oriented polymorphism. This design Using the information from the COUser context, the 
cleanly separates the specific implementations which are 55 backplane knows which COApps to provide, e.g., which 
browser-specific from the browser-independent COSecurity buttons to install in its toolbar. The backplane stores the user 
object. specific entitlements in memory for other processes to 
Each COApp object may cither create their own COS- access. After determining the entitlements, the backplane 
ccurity object using the public constructors, or retrieve the initiates a new thread and starts an application toolbar in step 
CoSecurity object used by the backplane via 60 310. The application toolbar includes the services to which 
COBackPlane.getSecurityO. In general, the developer of the the remote user has subscribed and may select to run. From 
applications to be run will use the CoSecurity object when- the application toolbar, a user is able to select a service to 
ever the COApp needs privileged access to any local run. Upon user selection, the selection is communicated 
resource, i.e., access to the local disk, printing, local system from the application toolbar to the backplane in steps 312, 
properties, and starting external processes, llie following 65 314, which then launches the graphical user interface pro- 
represents an example of the code generated when using the gram associated with the selected service. The application 
security object. toolbar remains on the user display, even after a particular 
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service has been initiated. This is useful when a remote user 
desires to start up another service directly from having run 
a previous service because the user then need not retrieve the 
home page again. 

If it is determined that the user entered password is not 
valid in step 290 or step 296, an attempted logon count is 
incremented in step 316. If the user's attempted logon count 
is greater than a predefined allowed number of tries as 
indicated in step 318, a message is conveyed to the user in 
step 320 and the user must restart the browser. If the user's 
attempted logon count is not greater than the predefined 
allowed number of tries, a "failed login" message is con- 
veyed to the user in step 322, and the user is prompted to 
reenter name/password in step 288. If it is determined that 
the user password has expired, the user is prompted to 
change the password in step 324. For example, the user may 
be required to change the password every 30 days for 
security reasons. Whenever the user changes the password, 
the new password is transmitted in real time to a server 
responsible for updating and keeping the password entry for 
the user. The user than enters the new password in step 324 
and continues with the processing described above in step 
290. 

The present invention includes a user unit for representing 
a user of a current session. The user unit is generally 
implemented as a COUser class extending Java. lang.Object. 
ITie COUser class object typically holds information includ- 
ing a user profile, applications and their entitlements. In 
order to minimize network traffic, the amount of data carried 
by the COUser is minimal initially, and becomes populated 
as requests are processed. The requests are generally pro- 
cessed by retrieving information from the Order Entry 
service. The profile information is then stored and populated 
in the COUser object should such information be requested 
again. 

A COUser object is created when the tiser logs in, and 
holds the username and password of the user as an object in 
the COClientSession object. The session object is contained 
within the backplane, which manages the session throughout 
its lifetime. The code below illustrates how this occurs: 



// Within the backplane 

CXX;{icntSession session ■ new COClientSessionO; 
try { 

Session. logon ("xiseraame", "password"); 
} catch (COClicntljOgon Exception e) { . . . }; 
// Should the User object be required 
COUser user = session.gctUserO; 



The logon method of the COClientSession object commu- 
nicates with the Order Entry server, a back-end authentica- 
tion mechanism, for authenticating the user 

The COUser that may be obtained from the COClient- 
Session immediately after the login process is very sparse. 
It includes a limited set of information such as useraame, a 
list of applications that user is entitled to, for example. The 
details of each entitlement information are retrieved at the 
time of actual processing with those information. 
Session Security As described previously, the SSL protocol 
includes one level of session security, and may negotiate and 
change in cipher code between sessions. Additionally, the 
present invention employs the "cookie" feature set of con- 
temporary browsers to maintain session security, and pre- 
vent session hijacking or the use of a name and password 
obtained by snilEng, spoofing or EMR monitoring. 

FIG. 11 is a data flow diagram illustrating data flow 
among the processing modules of the "network MCI Inter- 
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act" during logon, entitlement request/response, heartbeat 
transmissions and logoff procedures. As shown in FIG. 11, 
the client platform includes the networkMCI Interact user 
340 representing a customer, a logon Web page having a 

5 logon object for logon processing 342, a home page having 
the backplane object. The Web server 344, the dispatcher 
server 346, cookie jar server 352, and StarOE server 348 are 
typically located at the enterprise site. 
As described above, following the SSL handshake, certain 

10 cab files, class files and disclaimer requests are downloaded 
with the logon Web page as shown at 440. At the logon Web 
page, the customer 340 then enters a userid and password for 
user authentication as illustrated at 440. The customer also 
enters disclaimer acknowledgment 440 on the logon page 

15 342. If the entered userid and password are not valid or if 
there were too many unsuccessful logon transactions, the 
logon object 342 communicates the appropriate message to 
the customer 340 as shown at 440, A logon object 342, 
typically an applet launched in the logon Web page connects 

20 to the Web server 344, for communicating a logon request to 
the system as shown at 442. The logon data, having an 
encrypted userid and password, is sent to the dispatcher 346 
when the connection is established as shown at 444. The 
dispatcher 346 then decrypts the logon data and sends the 

25 data to the StarOE 348 after establishing a connection as 
shown at 446. The StarOE 348 validates the userid and 
password and sends the results back to the dispatcher 346 as 
illustrated at 446 together with the user application entitle- 
ments. The dispatcher 346 passes the data results obtained 

30 from the StarOE 348 to the Web server 344 as shown at 444, 
which passes the data back to the logon object 342 as shown 
at 442. The customer 340 is then notified of the logon results 
as shown as 440. 
When the customer 340 is validated properly, the cus- 

35 tomer is presented with another Web page, referred to as the 
home page 350, from which the backplane is typically 
launched. After the user validation, the backplane generally 
manages the entire user session until the user logs off the 
"networkMCI Interact." As shown at 448, the backplane 

40 initiates a session heartbeat which is used to detect and keep 
the communications alive between the client platform and 
the enterprise Intranet site. The backplane also instantiates a 
COUser object for housekeeping of all client information as 
received from the StarOE 348. For example, to determine 

45 which applications a current customer is entitled to access 
and to activate only those application options on the home 
page for enabling the customer to select, the backplane sends 
a "get application list" message via the Web server 344 and 
the dispatcher 346 to the StarOE 348 as shown at 448, 444, 

50 and 446. The entitlement list for the customer is then sent 
from the StarOE 348 back to the dispatcher 346, to the Web 
server 344 and to the backplane at the home page 350 via the 
path shown at 446, 444, and 448. The application entitle- 
ments for the customer are kept in the COUser object for 

55 appropriate use by the backplane and for subsequent 
retrieval by the client applications. 

The entitlement information for COUser is stored in a 
cookie jar 352, maintained in the cookie jar server 32 or the 
dispatcher server 26 (illustrated in FIGS. 4 and 5). When the 

60 Web server receives the entitlement requests from the back- 
plane at the home page 350 or from any other client 
applications, the Web server 344 makes a connection to the 
cookie jar 352 and checks if the requested information is 
included in the cookie jar 352 as shown at 450. The cookie 

65 jar 352 is a repository for current customer sessions and the 
individual session details are included in a cookie including 
the entitlement information from the OE server 348. During 
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the logon process described above, the OE server 348 may 
include Id its response, the entitlements for the validated 
ctistomer. The dispatcher 346 transfers the entitlement data 
to the Web server 344, which translates it into a binary 
format. The Web server 344 then transmits the binary 
entitlement data to the cookie jar 352 for storage and 
retrieval for the duration of a session. Accordingly, if the 
requested information can be located in the cookie jar 352, 
no further request to the StarOE 348 may be made. This 
mechanism cuts down on the response time in processing the 
request. Although the same information, for example, cus- 
tomer application entitlements or entitlements for corp ids, 
may be stored in the COUser object and maintained at the 
client platform as described above, a second check is usually 
made with the cookie jar 352 via the Web server 344 in order 
to insure against a corrupted or tampered COUser object's 
information. Thus, entitlements are typically checked in two 
places: the client platform 10 via COUser object and the 
Web server 344 via the cookie jar 352. 

When a connection is established with the cookie jar 352, 
the Web server 344 makes a request for the entitlements for 
a given session as shown at 450. The cookie jar 352 goes 
through its stored list of cookies, identifies the cookie for the 
session and returns the cookie to the Web server 344 also 
shown at 450. llie Web server 344 typically converts the 
entitlements which are received in binary format, to string 
representation of entitlements, and sends the entitlement 
string back to the backplane running on the client platform 
10. 

Furthermore, the cookie jar 352 is used to manage heart- 
beat transactions. Heartbeat transactions, as described 
above, are used to determine session continuity and to 
identify those processes which have died abnormally as a 
result of a process failure, system crash or a communications 
failure, for example. During a customer session 
initialization, the cookie jar 352 generates a session id and 
sets up "heartbeat" transactions for the customer's session. 
Subsequently, a heartbeat request is typically sent from a 
process running on a client platform to the Web server 344, 
when a connection is established, as shown at 448. The Web 
server 344 connects to the cookie jar 352 and requests 
heartbeat update for a given session. The cookie jar 352 
searches its stored list of cookies, identifies the cookie for 
the session and updates the heartbeat time. The cookie jar 
352 then sends the Web server 344 the updated status 
heartbeat as shown at 450. The Web server 344 then sends 
the status back to the client platform process, also as shown 
at 450. 

When a customer wants to logoff, a logoff request trans- 
action may be sent to the Web server 344. The Web server 
344 then connects to the cookie jar 352 and requests logoff 
for the session as shown at 450. The cookie jar 352 identifies 
the cookie for the session and deletes the cookie. After 
deleting the cookie, the cookie jar 352 sends a logoff status 
to the Web server 344, which returns the status to the client 
platform. 

Other transaction requests are also sent via the Web server 
344 and the cookie jar 352 as shown in FIG. 12. FIG. 12 is 
a data flow diagram for various transactions communicated 
in the system of the present invention. Typically, when a 
customer enters a mouse click on an application link as 
shown at 460, an appropriate transaction request stream is 
sent to the Web server as shown at 462. The Web server 344 
typically decrypts the transaction stream and connects to the 
cookie jar 352 to check if a given session is still valid as 
shown at 464. The cookie jar 352 identifies the cookie for the 
session and sends it back to the Web server 344 as shown at 
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464. The Web server 344 on receipt of valid session connects 
to the dispatcher 346 and sends the transaction request as 
shown at 466. When the dispatcher 346 obtains the request, 
it may also connect to the cookie jar 352 to validate the 

5 session as shown at 468. The cookie jar 352 identifies the 
cookie for the session and sends it back to the dispatcher 346 
as shown at 468. The dispatcher 346, upon receiving the 
valid session connects to a targeted application server or 
proxy 354, which may include StarOE, and sends the request 

10 transaction to the target as shown at 470. The server or proxy 
354 processes the request and sends back the response as 
stream of data which is piped back to the dispatcher 346 as 
shown at 470. The dispatcher 346 pipes the data back to the 
Web server 344 as shown at 466, which encrypts and pipes 

15 the data to the client platform as shown at 462, referred to 
as the home page 350 in FIG. 12. 

The present invention includes a client communications 
unit for providing a single interface from which the back- 
plane and the applications may send messages and requests 

20 to back-end services. The client communications unit 
includes a client session unit and a transactions unit. The 
client session unit and the transactions unit comprise classes 
used by client applications to create objects that handle 
communications to the various application proxies and/or 

25 servers. Generally, the entire communications processes 
start with the creation of a client session after a login 
process. This is started through the login process. The iLser 
logs into user's Web page with a username and password. 
During a login process, a remote client session object of 

30 class COClientSession is created, and the COClientSession 
object passes the username and password information pair 
obtained from the login process to a system administrative 
service which validates the pair. The following code instruc- 
tions are implemented, for example, to start up a session 

35 using the COClientSession class. 



COClientSession ss - new CCX^lientSessionQ; 
try { 

ss.sctURL(urlString); 

ss . I ogo n(*' jsm ith", " m yPassword"); 
} catch (CoClicntLogon Exception e) { . . . 
} catch (MalformcdURLExccption e) { . . . }; 



45 In addition, the COClientSession object includes a refer- 
ence to a valid COUser object associated with the user of the 
current COClientSession object. 

The client session object also provides a session, where a 
customer logs on to the system at the start of the session, and 

50 if successfully authenticated, is authorized to use the system 
until the session ends. The client session object at the same 
time provides a capability to maintain session-specific infor- 
mation for the life/duration of the session. Generally, com- 
munications to and from the client takes place over HTTPS 

55 which uses the HTTP protocols over an SSL encrypted 
channel. Each HTTP request/reply is a separate TCP/IP 
connection, completely independent of all previous or future 
connections between the same server and client. Because 
HTTP is stateless, meaning that each connection consists of 

60 a single request from the client which is answered by a 
single reply by a server, a novel method is provided to 
associate a given HTTP request with the logical session to 
which it belongs. 

When a user is authenticated at login via the system 

65 administrative server, the client session object is given a 
session identifier or "cookie," a unique server-generated key 
which identifies a session. The session key is typically 
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encapsulated in a class COWebCookie, "public COWeb- 
Cookie (int value)/' where value represents a given cookie's 
value. Hie client session object holds this key and returns it 
to the server as part of the subsequent HTTP request. The 
Web server maintains a "cookie jar*' which is resident on the 
dispatcher server and which maps these keys to the associ- 
ated session. This form of session management also func- 
tions as an additional authentication of each HTTPS request, 
adding security to the overall process. In the preferred 
embodiment, a single cookie typically suffices for the entire 
session. Alternately, a new cookie may be generated on each 
transaction for added security. Moreover, the cookie jar may 
be shared between the multiple physical servers in case of a 
failure of one server. This mechanism prevents sessions 
being dropped on a server failure. 

In addition, to enable a server software to detect client 
sessions which have "died," e.g., the client session has been 
disconnected from the server without notice because of a 
client-side crash or network problem, the client application 
using the client session object "heartbeats" every predefined 
period, e.g., 1 minute to the Web server to "renew" the 
session key (or record). The Web server in turn makes a 
heartbeat transaction request to the cookie jar. Upon receipt 
of the request, the cookie jar service "marks" the session 
record with a time stamp indicating the most recent lime the 
client communicated to the server using the heartbeat. The 
cookie jar service also alarms itself, on a configurable 
period, to read through the cookie jar records (session keys) 
and check the time stamp (indicating the time at which the 
client was last heard) against the current time. If a session 
record's deha is greater than a predetermined amount of 
time, the cookie jar service clears the session record, effec- 
tively making a session key dead. Any subsequent transac- 
tions received with a dead session key, i.e., nonexistent in 
the cookie jar, are forbidden access through the Firewall. 

The heartbeat messages are typically enabled by invoking 
the COClientSession object's method "public synchronized 
void enableSessionHeartbeat (boolean enableHeartbeat)," 
where enableHeartbeat is a flag to enable or disable heart- 
beat for a session. The heartbeat messages are typically 
transmitted periodically by first invoking the COClientSes- 
sion object's method "public synchronized void setHeart- 
beatlnterval (long millsecslnterval)," where the heartbeat 
interval is set in milliseconds, and by the COClientSession 
object's method "protected int startHeartbeatQ," where the 
heartbeat process starts as soon as the heartbeat interval is 
reached. Failure to "heartbeat" for consecutive predefined 
period, e.g., one hour, would result in the expiration of the 
session key. 

Enterprise Security Enterprise Security is directed to the 
security of the enterprise network and the data maintained 
by the various enterprise applications with respect to the 
open nature of the Internet, and the various attacks on the 
system or data likely to result from exposure to the Internet. 
Usual enterprise security is focused on internal procedures 
and employees, since this represents the biggest single area 
of exposure. Strong passwords, unique user Ids and the 
physical security of the workstations are applicable to both 
internal employees and external customers and users who 
will access the enterprise applications. It is noted that many 
of the previously described feamres relating to data encryp- 
tion for communications security and session security are 
essential parts of enterprise security, and cooperate with 
enterprise architecture and software infrastructure to provide 
security for the enterprise. 

For example, as will be hereinafter described in detail, the 
present invention uses strong symmetric key encryption for 
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communications through the firewalls to the application 
servers. This internal symmetric key encryption, when 
coupled with external public key encryption provides an 
extra level of security for both the data and the software 

s infrastructure. 

FIG. 5 is a diagram depicting the physical networkMCI 
Interact system architecture 10. As shown in FIG. 5, the 
system is divided into three major architectural divisions 
including: 1) the customer workstation 10 which includes 

10 those mechanisms enabling customer connection to the 
Secure web servers 24; 2) a secure network area 17, known 
as the DeMilitarized Zone "DMZ" set aside on MCI pre- 
mises double firewalled between the public Internet 15 and 
the MCI Intranet 66 to prevent potentially hostile customer 

15 attacks; and, 3) the MCI Intranet Midrange Servers 40 and 
Legacy Mainframe Systems 20 which comprise the back end 
business logic applications. ^ 

As illustrated in FIG. 5, the present invention includes a 
double or complex firewall system that creates a "demilila- 

20 rized zone" (DMZ) between two firewalls 29fl, 296. ^ 
In the preferred embodiment, a hybrid or complex gate- 
way firewall system is used, and the firewalls 29(fl),(6) of 
FIGS. 1, 4 and 5 are illustrative to represent the concept 
diagrammatically. In the preferred embodiment, they may 

25 include port specific filtering routers, which may only con- 
nect with a designated port address. For example, router 
29(a) may connect only to the addresses set for the 
HydraWebt® 45 (or web servers 24) within the DMZ, and 
router 29(b) may only connect to the port addresses set for 

30 the dispatcher server 26 within the network. In addition, the 
dispatcher server connects with an authentication server, and 
through a proxy firewall to the application servers. This 
ensures that even if a remote user ID and password are 
hijacked, the only access granted is to one of the web servers 

35 24 or to intermediate data and privileges authorized for that 
user. Further, the hijacker may not directly connect to any 
enterprise server in the enterprise intranet beyond the DMZ, 
thus ensuring internal company system security and integ- 
rity. Even with a stolen password, the hijacker may not 

40 connect to other ports, root directories or application servers 
within the enterprise system, and the only servers that may 
be sabotaged or controlled by a hacker are the web servers 
24. 

The DMZ acts as a double firewall for the enterprise 

45 intranet because of the double layer of port specific filtering 
rules. Further, the web servers 24 located in the DMZ never 
store or compute actual customer sensitive data. The web 
servers only transmit the data in a form suitable for display 
by the customer's web browser. Since the DMZ web servers 

50 do not store customer data, there is a much smaller chance 
of any customer information being jeopardized in case of a 
security breach. In the preferred embodiment, firewalls or 
routers 29 (a),(b) are a combination of circuit gateways and 
filtering gateways or routers using packet filtering rules to 

55 grant or deny access from a source address to a destination 
address. All connections from the internal application serv- 
ers are proxied and filtered through the dispatcher before 
reaching the web servers 24. Thus it appears to any remote 
site, that the connection is really with the DMZ site, and 

60 identity of the internal server is doubly obscured. This also 
prevents and direct connection between any external and any 
internal network or intranet computer. 

The filtering firewalls 29 (a), (b) may also pass or block 
specific types of Internet protocols. For example, FTP can be 

65 enabled only for connections to the In-Box server 41, and 
denied for all other destinations. SMTP can also be enabled 
to the In-Box server, but Telnet denied- The In-box server 41 
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is a store and forward server for client designated reports, 3. Common content storage shared across all the servers, 
but even in this server, the data and meta-data are separated File servers, such as Raid 0+1, NFS and others may be used 
to further secure the data. to provide HA in the event of disk, machine, or interface 
As previously described, the customer access mechanism failure. The administrative overhead is reduced because of 
is a client workstation 10 employing a Web browser 14 for 5 commonality of the content, scaling is easy since it is a 
providing the access to the networkMCI Interact system via network resource, and a common cache for customer state, 
the public Internet 15. When a subscriber connects to the As shown in FIG. 14, a configuration using Hydra WEB 
networkMCI Interact Web site by entering the appropriate 45 for virtual IP addressing, multiple Web servers 24, and 
URL, a secure TCP/IP communications link 22 is estab- file servers for content storage 240. The file server is not 
lished to one of several Web servers 24 located inside a first lo required to provide content storage, content can be trans- 
firewall 29a in the DMZ 17. Preferably at least two web ferred from master copy to Web machines using a mecha- 
servers are provided for redundancy and failover capability. nism such as FTP or rdist. If a file server is not used then 
In the preferred embodiment of the invention, the system client state information will be maintained through server to 
employs SSL encryption so that communications in both server communication. 

directions between the subscriber and the networkMCI is Using a file server gives a security advantage over local 

Interact system are secure. disk, content can be mounted read only, so in the event of a 

In the present embodiment, the DMZ Secure Web servers web system compromise the content storage will not be 

24 are presently DEC 4100 systems having Unix or corrupted. 

NT-based operating systems for running services such as As shown in FIG. 15, an alternative to using a file server 

HTTPS, FTP, and Telnet over TCP/IP. The web servers may 20 would be to put all content on each server 24. This improves 

be interconnected by a fast Ethernet LAN running at 100 local performance and isolates Web servers from each other. 

Mbit/sec or greater, preferably with the deployment of Ideally all Web servers 24 will be updated at once with any 

switches within the Ethernet LANs for improved bandwidth changes to Web content. With multiple machines this is 

utilization. One such switching unit included as part of the possible through a number of schemes. Unix provides rdist, 

network architecture is a HydraWEB*^" unit 45, manufac- 25 CPIO, FTP and others, which can update content on local 

tured by Hydra WEB Technologies, Inc., which provides the disk. 

DMZ with a virtual IP address so that subscriber HTTPS As shown in FIG. 5, the most available Web server 24 

requests received over the Internet will always be received. receives subscriber HTTPS requests, for example, from the 

The Hydra web unit 45 implements a load balancing algo- HydraWEB'*'" 45 over a connection 35a and generates the 

rithm enabling intelligent packet routing and providing 30 appropriate encrypted messages for routing the request to 

optimal reliability and performance by guaranteeing acces- the appropriate MCI Intranet midrange web server over 

sibility to the "most available" server. It particularly moni- connection 35i>, router 55 and connection 23. Via the 

tors all aspects of web server health from CPU usage, to Hydraweb unit 45, a TCP/IP connection 38 links the Secure 

memory utilization, to available swap space so that Intemet/ Web server 24 with the MCI Intranet Dispatcher server 26. 

Intranet networks can increase their hit rate and reduce Web 35 Further as shown in the DMZ 17 is a second RTM server 

server management costs. In this manner, resoiuce utihza- 52 having its own connection to the public Intemet via a 

tion is maximized and bandwidth (throughput) is improved. TCP/IP connection 32. As described in co-pending U.S. 

It should be understood that a redimdant Hydraweb unit may patent application No. 09/159,516, filed Apr. 11, 2001, now 

be implemented in a Hot/Standby configuration with heart- U.S. Pat. No. 6,470,386, this server provides real-time 

beat messaging between the two units (not shown). 40 session management for subscribers of the networkMCI 

Moreover, the networkMCI Interact system architecture Interact Real Time Monitoring system. An additional TCP/ 

affords web server scaling, both in vertical and horizontal IP connection 48 links the RTM Web server 52 with the MCI 

directions. Additionally, the architecture is such that new Intranet Dispatcher server 26. 

secure web servers 24 may be easily added as customer With more particularity, as further shown in FIG. 5, the 

requirements and usage increases. The use of the 45 networkMCI Interact physical architecture includes two 

Hydra WEB™ enables better load distribution when needed routers: a first router 55 for routing encrypted subscriber 

to match performance requirements. messages from a Secure Web server 24 to the Dispatcher 

There are two ways a web server can be scaled, vertically, server 26 located inside the second firewall 29b; and, a 

within a single machine with large CPU, disk, network I/O, second router 65 for routing encrypted subscriber messages 

etc., capacity, and, horizontally, distributed across multiple 50 from the RTM Web server 52 to the Dispatcher server 26 

machines giving both scaling and service availability. This inside the second firewall. In the preferred embodiment, the 

architecture has no single point of failure. routers are manufactured by Cisco Systems, Inc. Although 

In horizontally distributed web servers as shown in FIGS. not shown, each of the routers 55, 65 may additionally route 

14 and 15, it is important to maintain a state of a user signals through a series of other routers before eventually 

connection because if a connection is lost the client appli- 55 being routed to the nMCI Interact Dispatcher server 26, In 

cation can then continue using another Web server. In this operation, each of the Secure servers 24 function to decrypt 

architecture any server can pick up a client connection and the client message, presentably via the SSL implementation, 

continue. and unwrap the session key and verify the users session from 

There are three basic requirements for horizontally dis- the COUser object authenticated at Logon, 

tributed web servers: 60 After establishing that the request has come from a valid 

1, Either a single virtual IP address, eliminating the need user and mapping the request to its associated session, the 
for high availability (HA) redundancy in the server pool to Secure Web servers 24 will re-encrypt the request using RSA 
provide IP failover, or a pool of addresses that can be drawn encryption and forward it over a second secure socket 
from, usually implemented using round robin DNS. connection 23 to the dispatcher server 26 inside the enter- 

2. Multiple machines that run the same software, allowing 65 prise Intranet. 

a lower entry point to Web based service as long as the FIGS. 13(a) and 13(6) are schematic illustrations showing 

machines can handle some excess capacity. the message format passed between the dispatcher 26 and 
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the relevant application specific proxy, (FIG. 13(a)) and the 
message formal passed between the application specific 
proxy back to the Dispatcher 26 (FIG. 13(i?)). As shown in 
FIG. 13(fl), all messages between the Dispatcher and the 
Proxies, in both directions, begin with a common header 150 
to allow leverage of common code for processing the 
messages. A first portion of the header includes the protocol 
version 165 which may comprise a byte of data for identi- 
fying version control for the protocol, i.e., the message 
format itself, and is intended to prevent undesircd mis- 
matches in versions of the dispatcher and proxies. The next 
portion includes the message length 170 which, preferably, 
is a 32-bit integer providing the total length of the message 
including all headers. Next is the echo/ping flag portion 172 
that is intended to support a connectivity test for the 
dispatcher-proxy connection. For example, when this flag is 
non-zero, the proxy immediately replies with an echo of the 
supphed header. There should be no attempt to connect to 
processes outside the proxy, e.g. the back-end application 
services. The next portion indicates the Session key 175 
which is the unique session key or "cookie" provided by the 
Web browser and used to uniquely identify the session at the 
browser. As described above, since the communications 
middleware is capable of supporting several types of trans- 
port mechanisms, the next portion of the common protocol 
header indicates the message type/mechanism 180 which 
may be one of four values indicating one of the following 
four message mechanisms and types: l)Synchronous 
transaction, e.g., a binary 0; 2) Asynchronous request, e.g., 
a binary 1; 3) Asynchronous poll/reply, e.g., a binary 2; 4) 
bulk transfer, e.g., a binary 3. 

Additionally, the common protocol header section 
includes an indication of dispatcher-assigned serial number 
185 that is unique across all dispatcher processes and needs 
to be coordinated across processes (like the Web cookie (see 
above)), and, further, is used to allow for failover and 
process migration and enable multiplexing control between 
the proxies and dispatcher, if desired. A field 140 indicates 
the status is unused in the request header but is used in the 
response header to indicate the success or failure of the 
requested transaction. More complete error data will be 
included in the specific error message returned. The status 
field 140 is included to maintain consistency between 
requests and repHes. As shown in FIG. 13(fl), the proxy 
specific messages 178 are the metadata message requests 
from the report requester client and can be transmitted via 
synchronous, asynchronous or bulk transfer mechanisms. 
Likewise, the proxy specific responses are metadata 
response messages 180 again, capable of being transmitted 
via a synchronous, an asynchronous or bulk transfer trans- 
port mechanism. 

It should be understood that the application server proxies 
can either reside on the dispatcher server 26 itself, or, 
preferably, can be resident on the middle- tier application 
servers 40, i.e., the dispatcher front end code can locate 
proxies resident on other servers. 

As mentioned, the proxy vahdation process may include 
parsing incoming requests, analyzing them, and confirming 
that they may include validly formatted messages for the 
service with acceptable parameters. If necessary, the mes- 
sage is translated into an underlying message or networking 
protocol. If no errors are found, the proxy then manages the 
communication with the middle-tier server to actually get 
the request serviced. The application proxy supports appli- 
cation specific translation and communication with the back- 
end application server for both the Web Server (java applet 
originated) messages and application server messages. 
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Particularly, in performing the verification, translation 
and communication functions, the Report Manager server, 
the Report Scheduler server and Inbox server proxies each 
employ front end proxy C++ objects and components. For 

5 instance, a utils.c program and a C++ components library, is 
provided for implementing general functions/objects. Vari- 
ous C++ parser objects are invoked which are part of an 
object class used as a repository for the RM metadata and 
parses the string it receives. The class has a build member 

10 function which reads the string which includes the data to 
store. After a message is received, the parser object is 
created in the RMDispatcher.c object which is a file which 
includes the business logic for handling metadata messages 
at the back-end. It uses the services of an RMParser class, 

IS Upon determining that the client has sent a valid message, 
the appropriate member function is invoked to service the 
request. Invocation occurs in MCIRMServerSocket.C when 
an incoming message is received and is determined not to be 
a talarian message. RMSErverSocket.c is a class implement- 

20 ing the message management feature in the Report Manager 
server. Public inheritance is from MCIServerSocket in order 
to create a specific instance of this object. This object is 
created in the main loop and is called when a message needs 
to be sent and received; a Socket. c class implementing client 

25 type sockets under Unix using, e.g., TCP/IP or TCP/UDP. 
Socket. C is inherited by ClientSocket.C:: Socket 
(theSocketType, thePortNum) and ServerSocket.C:: Socket 
(theSocketTVpe, thePortNum) when ClientSocket or Serv- 
erSocket is created. A ServerSocket.C class implements 

30 client type sockets under Unix using either TCP/IP or 
TCP/UDP. ServerSocket.C is inherited by RMServerSocket 
when RMServerSocket is created. An InboxParser.c class 
used as a repository for the RM Metadata. The class' "build" 
member function reads the string which includes the data to 

35 store and the class parses the string it receives. After a 
message has been received, the MCIInboxParser object is 
created in inboxutl.c which is a file which includes the 
functions which process the Inbox requests, i.e. Add, Delete, 
List, Fetch and Update. Additional objects/classes include: 

40 Environ.c which provides access to a UNIX environment; 
Process.c which provides a mechanism to spawn child 
processes in the UNIX environment; Daemon. c for enabling 
a process to become a daemon; Exception.c for exception 
handling in C++ programs; and, RMlog.c for facilitating RM 

45 logging. In addition custom ESQL code for RM/database 
interface is provided which includes the ESQC C interface 
(Informix) stored procedures for performing the ARD, DRD, 
DUR, URS, GRD, CRD, and GPL messages. The functions 
call the stored procedures according to the message, and the 

50 response is built inside the functions depending on the 
returned values of the stored procedures. A mainsql.c pro- 
gram provides the ESQL C interface for messages from the 
report manager and report viewer. 

Outgoing (server-to-client) communications follow the 

55 reverse route, i.e., the proxies feed responses to the decode/ 
dispatcher server 26 and communicate them to the DMZ 
Web servers 24 over the socket connection. The Web servers 
26 will forward the information to the client 10 using SSL. 
The logical message format returned to the client from the 

60 middle tier service is shown as follows: 



IfrCP/IP Ijencryption I|http ||web response ||dispatcher response 
llproxy-spccific response j| 

65 

where "||" separates a logical protocol level, and protocols 
nested from left to right. 



04/21/2004, EAST version: 1.4.1 



us 6,6( 

27 

Application Security 

Application security relates to the security within the 
legacy application that determines authorization for com- 
mand and control, read, write and modify files, and print and 
report options inherent to the application. Inasmuch as the 
present invention is intended to link a number of disparate 
legacy applications to a common interface, a provision must 
be made at the application server level to satisfy the appli- 
cation security requirements of the legacy application. 

In the present invention, the user id, the user's password 
authentication, and the user's application entitlements are 
stored on the SlarOE server 49, as previously described with 
respect to FIGS. 4 and 5. At log-on. The initial population of 
COUser object, as indicated at step 308 in FIG. 10, is sparse 
and initially only represents entitlements to one or more 
specific applications. When the user logs into a specific 
application, the application server retrieves specific and 
detailed user entitlements for that application from the 
StarOE server 49 in a separate transaction. These entitle- 
ments may be different from application to application. 
Thus, a user may have read and write privileges with respect 
to one legacy application, only read privileges with respect 
to another legacy application. 

A representative example is illustrated in FIG, 16 and will 
be described with respect to the Toll Free Network Manager 
application provided through the TFNM server 45 as illus- 
trated in FIGS. 4 and 5. It is understood that this description 
is representative of application security in general, and that 
the application level security features may vary from legacy 
application to legacy application depending on the needs of 
the legacy application and the functions provided through it. 

As shown in FIG. 16, when a user 10 logs into the 
enterprise network over the Internet and selects a specific 
application 47, the user's logon password and user ID, 
entered on a user's Web page 230, is verified by StarOE 49. 
The application 47 calls StarOE 49 asking for the User 
Security information which includes an Enterprise ID, Corp 
IDs, and Racf IDs associated with the Corp IDs. The 
application 47 then calls Netcap 20 (b) for a function level 
security profile based on Racf ID and Corp ID. If the user 
has Enterprise level security, Netcap 20(b) is called for the 
list of Coips for that Enterprise. 

When the Web page 230 is accessed, the user logs in and 
a User Common Object is created. At this point, a message 
is sent via the Dispatcher to the StarOE Server 49 to validate 
a user. When the user selects the application 47, through 
Java applets using TCP/IP from the home Web page 230, 
StarOE 49 validates the user's id and password. If 
successful, StarOE 49 allows the user into the application 
47. The application 47 server will send a SecRequest mes- 
sage to the StarOE server 49 directly requesting a user's 
security. SecRequest Message contains Userld, Enterprise 
Id, OEServer Address, OEServer Port. Enterprise Id is 
obtained from the Common User Object from the Platform. 

The StarOE server 49 sends a Security response SecRsp. 
This response contains a flag that marks the user as Produc- 
tion support Update, Production support Read-only or as a 
regular user. The user security profile, SccProfile, contains 
the list of Corp Ids that a User is allowed to access within 
the application 47. The data elements are: 

Corpld-Corp Id the user has access to within StarOE, 

Defaulllnd-Default Corpid Indicator having 'Y' or 

*N' values, 

Accessld-User's generated access Id (RACF ID). 

Once the user 10 logs into the application 47 and the 
SlarOE 49 security message has been received, then a 
Registry call is made to Netcap 20(^?) requesting a User 
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Security Profile. Security from Netcap 20(fc) is by Racf Id 
and Corp Id. For each Corp Id a user has access to, they must 
have a Racf Id. If a user has Enterprise level security, then 
the list of Corps under that Enterprise within Netcap have 
5 the same security as the Enterprise. 

While the invention has been particularly shown and 
described with respect to preferred embodiments thereof, it 
will be understood by those skilled in the art that the 
foregoing and other changes in form and details may be 
made therein without departing from the spirit and scope of 
the invention. 

We claim: 

1. A system for securing an enterprise communications 
network, said system having client access through the public 
Internet, said system comprising: 

(a) a first Internet firewall for accepting service requests 
from an enterprise client and routing said requests to 
one or more preselected addresses behind said firewall, 
said firewall permitting access in compliance with a 
first set of filtering rules; 

(b) at least one secure web server for receiving said 
service requests and managing a secure client session 
over the public Internet, said secure server providing 
session management for said service request, said ses- 

25 sion management including client identification, vah- 
dation and a session identifier to link said session with 
said client, wherein said session identifier is a web 
cookie generated by a separate server during an entitle- 
ments communications, after identification and valida- 

3Q tion of the client; 

(c) a second Internet/Internet firewaU for accepting ser- 
vice requests from a secure web server and routing said 
requests to one or more preselected addresses behind 
said firewall corresponding to dispatcher servers, said 

35 firewall permitting access in compliance with a second 
set of filtering rules; 

(d) at least one dispatcher server for communicating with 
said secure web server through a second firewall, said 
second firewall accepting services requests from said 

40 secure web server and routing said requests to said 
dispatcher server in compliance with a second set of 
filtering rules, said dispatcher server providing system 
access to said enterprise communications network after 
client entitlements have been verified; and 

45 (e) a plurality of proxy services linking said dispatcher 
server to a plurality of system resources over said 
communications network, said plurality of system 
resources providing communications network manage- 
ment capabilities for said enterprise client, said system 

50 resources responsive to service requests from said 
enterprise client to generate client data or instructions 
relating to said communications network. 

2. The system for securing an enterprise communications 
network as claimed in claim 1 wherein said secure web 

55 server communicates with said dispatcher server over an 
encrypted socket connection. 

3. The system for securing an enterprise communications 
network as claimed in claim 2 wherein said system includes 
encryption between said secure web server and said dis- 

60 patcher server. 

4. The system for securing an enterprise communications 
network as claimed in claim 3 wherein said system includes 
a first encryption algorithm for transmission of all ciistomer 
data between said secure web server and said dispatcher 

65 server, and a second encryption algorithm for transmission 
of all data between said secure web server and said enter- 
prise client. 



04/21/2004, EAST Version: 1.4.1 



us 6,6( 

29 

5. The system for securing an enterprise communications 
network as claimed in claim 1, wherein said system further 
comprises a plurality of secure web servers and a load 
balancing device for managing and distributing a plurality of 
client sessions across said plurality of secure web servers. 

6. The system for securing an enterprise communications 
network as claimed in claim 1 wherein said web cookie is 
wrapped and unwrapped by said secure web server at each 
service request to hnk a session with said client through a 
plurality of discrete client service requests in said session to 
verify said client to said dispatcher server at each transmis- 
sion of a service request in said session. 

7. Ilie system for securing an enterprise communications 
network as claimed in claim 6 which further includes a web 
browser for said client which provides secure socket layer 
encryption of client identification, authentication and said 
web cookie at each service request. 

8. The system for securing an enterprise communications 
network as claimed in claim 7 wherein said web cookies 
provide simultaneous session management for a plurality of 
system resources. 

9. A system for securing an enterprise communications 
network, said system having client access through the public 
Internet, said system comprising: 

(a) a first Internet firewall for accepting service requests 
from an enterprise client and routing said requests to 
one or more preselected addresses behind said firewall, 
said firewall permitting access in compliance with a 
first set of filtering rules; 

(b) a plurality of web servers having said preselected 
addresses for receiving said service requests and man- 
aging a plurality of client sessions over the public 
Internet, a load of said client sessions per each of said 
web servers is balanced by web balancers, each of said 
web servers providing session management for said 
service request, said session management including 
client identification, validation and a session identifier 
to link a session with a client, wherein said session 
identifier is a web cookie generated by a separate server 
during an entitlements communications, after identifi- 
cation and validation of the client; 

(c) at least one dispatcher server for communicating with 
said web servers through a second firewall, said second 
firewall accepting services requests from said web 
servers and routing said requests to said dispatcher 
server in compliance with a second set of filtering rules, 
said dispatcher server providing system access to said 
enterprise communications network after client entitle- 
ments have been verified; and 

(d) a plurality of proxy servers linking said dispatcher 
server to a plurality of application servers within said 
communications network, said application servers 
communicating with a plurality of system resources to 
provide communications network management capa- 
bilities for said enterprise clienLs. 

10. The system for securing an enterprise communica- 
tions network as claimed in claim 9 wherein said web 
servers are secure servers which encrypt each of said service 
requests with a first algorithm before transmission to said 
dispatcher server and a selected one of said proxy and said 
application servers. 

11. The system for securing an enterprise communications 
network as claimed in claim 9, said communications net- 
work further including an authentication server which deter- 
mines application server entitlements for said client follow- 
ing authentication. 

12. The system for securing an enterprise communica- 
tions network as claimed in claim 9, wherein said system 
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fiirther comprises a load balancing device for managing and 
distributing a plurality of client sessions across said plurality 
of web servers. 

13. The system for securing an enterprise communica- 
5 tions network as claimed in claim 9 wherein said unique web 

cookie is wrapped and unwrapped by said secure web server 
at each service request to link a session with said client 
through a plurality of discrete client service requests in said 
session to verify said client to said dispatcher server at each 
transmission of a service request in said session. 

14. The system for securing an enterprise communica- 
tions network as claimed in claim 10 which further includes 
a web browser for said client which provides secure socket 
layer (SSL) encryption of client identification, authentica- 
tion and said web cookie at each service request. 

15. The system for securing an enterprise communica- 
tions network as claimed in claim 14 wherein said system 
includes RSA encryption for transmission of all customer 
data between said plurality of secure web servers and said 
dispatcher server, and SSL encryption for transmission of all 
data between said secure web servers and said plurality of 
enterprise clients. 

16. A method of securing an enterprise communications 
network having public access via the public Internet, said 
method enabling access by a plurality of enterprise clients, 
said method comprising: 

(a) routing all public access requests to one or more first 
preselected addresses for response via a first set of 
routing rules; 

(b) authenticating a secure web server in response to said 
request for access and initiating a secure session with a 
client browser over the Internet; 

(c) encrypting communications between said client 
browser and said secure server with a first security 

35 protocol; 

(d) routing a request for client authentication and a set of 
client entitlements firom said secure server to a second 
preselected address at log-on via a second set of routing 
rules, wherein said client authentication and client and 

40 entitlements are provided by an authentication server; 

(e) encrypting communications within said network with 
a second security protocol; and 

(f) creating a session management object at each log-on to 
authenticate the client's browser to the enterprise net- 

45 work at each communication from the browser during 
the communications session, said session management 
object including client identification, validation and a 
session identifier to link a session with a client, wherein 
said session identifier is a unique web cookie generated 

50 by a separate server during an entitlements 
communications, after identification and validation of 
the client. 

17. The method of securing an enterprise communications 
network as claimed in claim 16, said method further com- 

55 prising the step of providing a plurality of application 
resources to one of said plurality of enterprise clients within 
said network in accordance with entitlements determined for 
said one of said plurality of clients at authentication. 

18. The method of securing an enterprise communications 
60 network as claimed in claim 16 which further includes the 

step of balancing a plurality of client requests across a 
plurality of secure web servers to improve response time for 
each client session. 

19. The method of securing an enterprise communications 
65 network as claimed in claim, 17, said method further com- 
prising the steps of packet filtering communications between 
said client browser and said secure web server. 
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20. The method of securing an enterprise communications 
network as claimed in claim 19, said method further com- 
prising the step of creating a proxy to filter communications 
between said secure web server and an application resource 
within said network. 5 

21. The method of securing an enterprise communications 
network as claimed in claim 18, wherein said method further 
includes public key encryption for encrypting communica- 
tions between the client browser and the network. 

22. The method of securing an enterprise communications lO 
network as claimed in claim 18 which uses a negotiated SSL 
protocol to authenticate the secure web server and encrypt 
communications between the client browser and the secure 
web server. 

23. The method of securing an enterprise communications 35 
network as claimed in claim 18, wherein public key encryp- 
tion is used for said second security protocol within said 
network. 
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24. The method of securing an enterprise communications 
network as claimed in claim 16, wherein said method further 
includes the step of embedding calls to Java applets in a 
logon page presented to a one of said plurality of clients at 
log on, one of said applets creating said session management 
object in said one client browser. 

25. The method of securing an enterprise communications 
network as claimed in claim 17, wherein said method further 
includes the step of downloading a collection of Java objects 
to said client browser for session management following a 
successful log on, said collection of objects enabling com- 
munications with said application resources during said 
session. 

26. The method of securing an enterprise communications 
network as claimed in claim 24, further comprising the step 
of examining said unique cookie at each session transmis- 
sion to maintain session security. 

* 4t « * * 
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